1. Field of the Invention
This invention relates generally to methods, machine readable media and apparatus for protecting intellectual property (“IP”). More specifically, this invention relates to a technique for providing controlled use of IP.
2. Description of Related Art
Electronic design automation (“EDA”) is becoming increasingly complicated and time consuming, due in part to the greatly increasing size and complexity of the electronic devices designed by EDA tools. Such devices include general purpose microprocessors as well as custom logic devices including programmable logic devices. The design of even the simplest of these devices typically involves generation of a high level design, logic simulation, generation of a network, timing simulation, etc.
A programmable logic device (“PLD”) is a programmable integrated circuit that allows the user of the circuit, using software control, to program the PLD to perform particular logic functions. A wide variety of these devices are manufactured by Altera Corporation of San Jose, Calif. A more complete description of these types of devices and their uses can be found at “www.altera.com” and in various materials published by Altera, but the basic structure and operation of PLDs are well known to those of ordinary skill in the art. Logic functions performed by small, medium, and large-scale integration integrated circuits can instead be performed by programmable logic devices. When an integrated circuit manufacturer supplies a typical programmable logic device, it is not yet capable of performing any specific function. The user, in conjunction with software supplied by the manufacturer or created by the user or an affiliated source, can program the PLD to perform a particular function or functions required by the user's application. The PLD then can function in a larger system designed by the user just as though dedicated logic chips were employed.
One such improvement is the development of so-called “megafunctions” by companies such as Altera Corporation. A more complete description of these megafunctions and their uses can be found at “www.altera.com” and in various materials published by Altera. Briefly, megafunctions are ready made, pre-tested functional blocks that complement and augment existing design methodologies. When implementing complex system architectures, these megafunctions significantly enhance the design process. By using megafunctions, designers can focus more time and energy on improving and differentiating their system-level product, rather than re-designing common, off the shelf functions.
Megafunctions are pre-verified design files for complex system-level functions which reduce the design task to creating the custom logic surrounding such commonly used system-level functions, dramatically shortening the design cycle and leveraging existing IP. Typically, an IP owner provides all of the files necessary to design with the megafunctions. Current practice allows designers to instantiate, compile and simulate a function to verify its size and performance. However, programming files and output files for EDA tool simulation can be generated only with an authorization code provided when the megafunction is licensed. Test vectors and a post-synthesis design file (a fully minimized and optimized netlist that can be used without risk of changes during processing) are supplied for simulation in appropriate software (such as Altera's MAX+PLUS II and QUARTUS software products).
A typical design cycle (using, for example, Altera's OpenCore technology) is shown in FIG. 1. A designer creates an initial block diagram 110 and subsequently identifies any megafunctions available for use in the anticipated system 120. The designer then can identify and evaluate one or more specific megafunctions 130 in terms of functionality and the range of parameterization available. After finding the appropriate megafunction(s), the designer installs the megafunction(s) 140 and, using software, simulates performance 150 within the anticipated circuitry and system.
However, software simulations of these megafunctions in complex IP frequently are limited in a number of respects. For example, many hours of software simulation of a circuit used in a voice over technology might translate into only a few seconds of equivalent simulated circuit activity on a hardware platform. As a further example, components of devices may be able to achieve an extremely high number of states, all of which the designer may need to test. However, due to the relatively slow speed of some software simulations, only a limited number of states might be testable by such software simulation. Because a hardware platform may run at much higher speeds than software simulations, a designer may need to test the design on a hardware platform as well. With regard to PLDs, software simulation for several hours (representing a few seconds of PLD hardware operation) might represent appropriate sample testing for a design. Yet, to thoroughly validate the core of a PLD used in such an application, the system must run for a minute or more, thus making thorough software simulation testing impractical. Therefore, complex IP (for example, in video applications or voice over IP) should be evaluated and validated on a hardware platform before being purchased. In such applications, in order to fully validate and complete the system's design, as called for in step 160, the system frequently operates on a hardware prototype platform for a longer period of time than is practical for software simulation. A hardware prototype platform is substantially identical to the production version of the hardware a designer intends to create. The hardware prototype can be a PLD or other device, or a system or subsystem of the total design to be created. As will be appreciated by those of ordinary skill in the art, the particulars of a hardware prototype are dependent upon the needs and circumstances of the project being undertaken by a designer and will vary widely. In the context of this disclosure, the term “hardware prototype” will mean any hardware platform suitable for testing the hardware and available software for the system being designed. The term “production hardware” means the desired final configuration of any hardware that the designer intends to achieve.
Once this prototype validation is completed, the IP used can be incorporated into specific devices 170 and be put into production use. This prior design process has allowed IP owners to control use of their IP up through design simulation (step 150 in FIG. 1). After software simulation and synthesis, the IP owner provides a temporary license file to a customer, which authorizes the customer to generate a programming object file (a “POF” file) of the design containing the IP and to establish the hardware prototype.
To date, IP owners have had to rely on legal contracts and/or other, unverifiable means to limit and control use of their IP on hardware platforms during prototype testing (step 150 of FIG. 1) and during production use (step 170 of FIG. 1). Customers have been able to generate a POF file that could be used both for prototype testing as well as in production. Unauthorized use in production deprives the IP owner of compensation for use of its IP and inhibits the owner's control of its property. Attempts at technical measures to prevent unauthorized use of IP also have been only modestly effective. For example, there have been attempts to send an entire prototype “package” (a PLD with the system installed and with its own power supply) to a customer for limited testing. Such a pre-packaged system was intended to allow hardware testing, without unauthorized production use. However, the delicate nature of these systems and the need for the IP owner to incur significant costs in this method make it unattractive and ineffective.
Techniques that permit more thorough development of digital systems and devices by designers while protecting the proprietary interests of the owners of the intellectual property incorporated in such systems and devices would represent a significant advancement in the art. Moreover, these techniques can be extended to allow an IP owner to limit or prevent unauthorized use of its IP in other settings and contexts.